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ABSTRACT 

A description is provided of the personnel subsystem 
of the computerized School Information System (SIS) developed by the 
Department of Advance Planning and Development of the Montgomery 
County, Maryland Public Schools. Other subsystems of SIS are being 
developed to deal with data relating to pupils, material, finance and 
facilities. The first section of the paper reviews the general design 
of the personnel subsystem, its design objectives, and its conceptual 
design. Brief mention is made of applications which are not 
operational, but which are planned for the areas of: 1) certification 
and in-service training, 2) payroll, 3) substitute teachers, and 4) 
application and recruitment. Lastly, detailed discussions of 
operational applications in the areas of personnel master files and 
position control are presented. (PB) 
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^ INTRODUCTION 

This paper describes a personnel system which is partially operational 
in Montgomery County Public Schools, Maryland. Montgomery County Public 
Schools is a large school district with approximately 127,000 pupils, 
198 schools, about 12,000 employees, and is geographically dispersed 
over 500 square miles. The Office of Planning, Management and Computer 
» Services is responsible for developing a large scale information system 

iU for the school system. 

There are four departments in that office. One is the Department 
of Program Planning and Coordination. Second is the Department of Records, 
Reports and Training. The third is the Department of Data Processing 
Operations, and the final is the Department of Advance Planning and 
Development. This latter department is responsible for the systems planning 
and design of information systems for the school district. The department 
is developing a School Information System which ultimately will be a 
data base oriented system in five areas — including the pupil, material, 
finance, facilities, and personnel subsystems. This paper will emphasize 
the Personnel Subsystem. I will first describe the general design of 
the subsystem as we conceive of it. Secondly will follow a description 
of some of the personnel applications, emphasizing only those which are 
operational at this point in time. 

GENERAL DESIGN OF THE PERSONNEL SYSTEM 

Personnel Processes 

The design started out with a very broad mceptual ization by identifying 
the personnel processes which normally take place in any school district. 
Starting with the authorization of a position for an employee, the processes 
go through application, recruitment, and selection, employee profile 
maintenance, certification, assignment and re-assignment, staff development, 
evaluation, employee benefits, employee relations, and termination. These 
are the processes or functions or activities that take place in dealing with 
personnel, and therefore they're the functions or activities which need to 
be addressed in some way in the automation of personnel activities. 
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Design Objectives 



The school system had developed some design objectives years ago in 
the personnel area. First of all, the need for a single data bank was 
identified. At the time it wasn't known exactly what was meant by a 
single data bank. Initially, we thought of it as a single file. Thinking 
is changing today toward what might be called a logical file. The school 
system will be using the data base software concept to identify a single 
data bank in the future. This data bank would be in three primary areas: 
applicants, employees 5 and positions. 

Standardized coding is a need as for most school districts which have 
any type of automation. There is generally a tendency to develop code 
structures unilaterally in an uncoordinated way. Montgomery County Schools 
has this problem and so wants to develop a coding structure that ties 
together all the applications. 

Centralized control of positions is another objective. The Personnel 
Office had what might be called a position control system but it was 
manual and very uncoordinated. The school system wanted to do something 
about that area. 

There was need to automate personnel actions so that when there 
was an employee action (whether a hire, transfer, termination, upgrading 
or certification) the people affected were notified — the employee, his 
manager, and the other offices in the personnel department that had to 
deal with the particular personnel action. 

We wanted to improve our information dissemination, and as will be 
shown later, we were particularly interested in the Cathode Ray Tube (CRT) 
as a means of disseminating information about employees. We wanted a skills 
inventory that would eventually tie in to the placement of employees and 
perhaps the certification of employees. We wanted to automate aspects of 
teacher substitute assignments. 

We wanted to integrate our personnel and payroll leave accounting 
which, as in many school districts, was developed in parallel but separate- 
ly. We wanted real time data entry and data retrieval. Finally we wanted 
to have some measure of data security in our personnel data base. 

We identified six major application areas as part of our personnel 
subsystem: 

- A personnel master file application which would be the depository 
for an employee's data; 

- A certification and in-service training application which would add 
additional data to the employee records; 

- Application and recruitment which would contain data about appli- 
cants and would be used as a resource for identifying applicants 
that could move into positions as they become vacant; 

- Position control to account for position authorization and to 
relate the authorization to the employees filling those 
authorizations; 



- Payroll ; and 

- Substitute assignments to improve our way of assigning substitutes 
and getting substitutes on a daily basis as the need dictates. 
The school system needs some 300 substitutes every day which becomes 
a problem. 

Conceptual Design 

The conceptual design of the Personnel Subsystem is basically simple. 
There are three major elements of that conceptual design — applicant file, 
employee file and position control file, all of which support the processes 
previously identified in a particular way (Figure 1). 

The design really starts with the position control application, which 
is the source for identifying the position that is available to be filled. 
That available position then would interact with the applicant file in 
order to identify applicants who would be suitable to fill that position. 

Notice in Figure 1 a "two" pointing from the employee file. Current 
employees are also a source of applicants. We would want to try to fill 
positions with in-house employees first. Also, we would want to make sure 
we could identify employees who were requesting transfer. Thus the employee 
file interacts with the applicant file as well as position control. 

Once an employee has applied and is evaluated, presumably an employee 
is selected. Therefore number 3 (Figure 1) indicates that the data then 
becomes resident in the employee file. At the same time the position control 
file indicates that the position is filled and with whom it is filled. 

Finally, (Figure 1, number 4) once the employee is on board, there 
are a number of activities which may take place to administer that employee. 
Activity may include a transfer in which case there would be interaction 
with the position control file to effect the transfer. Or there may be an 
upgrading or recertification. At the point of termination the employee 
file would interact with the position control file to vacate the position. 
Employee data would go into a history file. 

We conceive this as a simple system with three basic elements. I 
wouldn't want to convey that it's as simple to develop as it is to portray 
in concept 9 however. 

APPLICATIONS NOT YET OPERATIONAL 

The conceptual design includes six applications. Those applications 
which are not operational will not be described other than to mention some 
of our ideas of what we might be doing in the future in those areas. 

Certification and In-Service Training 

Certification and in-service training would address the whole process 
of certifying an employee, gathering the data into the automated data base 
which would indicate what level of certification might be appropriate. 
Eventually it would interact with the state certification program which is 
the ultimate certifier in the school district. In-service training would 
also provide data which would be used not only to record what type~of in- 
service training an employee has already had, but what type of training 
O miqht be needed — to identify deficiencies in training. 
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Regarding the payroll application, it is not necessary to say any more 
other than we have to pay our employees. They feel it's pretty important 
and we do too. We have an operational second generation payroll application 
although it's not integrated with our personnel data base at this point 
in time. 

Substitute Teachers 

The substitute teacher application conceptually would be used to 
identify those teachers that might fill a particular substitute need. 
There are a number of ways it could be designed. It could be an inter- 
active system where the principal might call the computer and get an 
audio response as to which substitutes were available. He would have 
an ability to enter which type of substitute could be reserved for a 
particular position. Conceivably, when the technology could provide the 
capability, the computer could literally call the substitute teacher 
and initiate the assignment. Some school districts have aspects of this 
capability operational already. We are at the point where we have the 
substitutes in the automated data base but have not yet initiated the 
procedure to tie it in to the substitute calling activity. 

Application and Recruitment 

We've done some work in the application and recruitment area, although 
we don't yet have this operational. We have gone through a preliminary 
system study which identifies the basic requirements of that application. 
The first requirement is a very typical one — that of reducing clerical 
work. We have had (about three years ago) some 10,000 to 12,000 applicants 
applying for positions in the school district. We don't have that many 
at this point. Yet a large number of applicants are vying for perhaps 
some 700 vacancies that might exist within the school district. It is a 
monumental task simply to keep track of these applicants and to make sure 
that they are properly administered and processed through the procedures. 
So we hope that through the computer we can reduce some of the clerical 
work in that activity. 

We want to develop a means of evaluating the recruitment and selection 
activities and procedures and identify how successful recruitment is. We 
have a university recruitment program in which our personnel people go out 
to universities to acquaint people with Montgomery County school district. 
We want to evaluate how effective our selection process is how well we're 
able to match the applicant to the particular job requirements. 

We want to develop a historical data bank on applicants so that should 
we have a future need that doesn't seem apparent now, we could go back 
into that data bank and get the data that would be necessary to fill the 
position. We want to support the recruitment activities to cluster 
requirements in a way that they could be used by the recruiters as they 
go out to the school districts. We want to improve the speed with which 
we can select people. With 10,000 applicants and a limited number of 
vacancies, the process is not rapid enough. We think using the computer 
could improve the speed with which we select employees. 
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The next requirement ties in very closely. We want to rapidly fill 
positions not only from sources external to the school district but from 
our employee files of people who might be requesting transfers. We. want 
more effective placement so that the people are happy in their position 
and the employer and supervisors are satisfied that they have the right 
type of person filling the job. 

OPERATIONAL APPLICATIONS , 

Personnel Master File Application 

Our personnel master file application is operational to a large 
extent. There are some data elements that we don't yet have operational 
on our data file. However, what we do have has been live for just under 
four years. It's built upon our 1401 system that we had designed back in 
the mid-60' s, expanded a great deal. 

We had a number of requirements for that particular application as 
well. We wanted a single data bank of all employees,, We wanted on-line 
data entry and inquiry, with a batch update on a daily processing basis. 
We wanted to develop employee profiles so we could take a given employee 
and identify the key elements of data that are associated with that 
employee. An off-line history, as mentioned earlier, was needed not 
only as a source of information for applicants, but so that if an employee 
should return to the school district, as does happen regularly, we would 
be able to retrieve that data and build the employee data bank from that 
historical record. 

We wanted automated Personnel Action Notices, and we wanted to be 
able to develop reports to our Board of Education. We wanted a capability 
for generation of employee evaluations -- a procedure where we could 
generate evaluation notices at the appropriate time during the year when 
they were required and some way of managing the receipt of employee 
evaluations for 12,000 employees, which is a tremendous administrative 
problem in our school district. 

We wanted to be able to simulate salaries to identify what it might 
cost should we change our salary scale in future years. As most of 
you are aware, we're very involved in negotiating with our professional 
association. Some years ago our teachers went on strike and this caused 
some very serious attention to the whole process of relating to the employees. 
We did develop the capability to simulate what it might cost for various 
alternative salary scales. This is used during our negotiation process. 

We wanted to develop salary notices so we could identify to our 
12,000 employees what grade, what step, and what assignment they were going 
to have in the coming year. We needed, as all of us do, to develop state 
reports and answers to inquiries for information from the state. We needed 
a Personnel Directory so we knew where our employees were and could contact 
them. 

We needed to develop committee assignments. As in many school districts, 
we have a large number of committees operational and wa wanted to make sure 



that we could spread the work load. We use the computer to keep track 
of what type of committee assignments our employees have. We wanted to 
know statistics about our turnover, how effective is our employee fringe 
benefit program, or how effective is our training program. We need this 
type of data to reduce employee turnover. And we need to record certifica- 
tion information and certification requirements in our personnel data base. 

Conceptually the design is simple. We have two different sources of 
information for entering data into our data base. Personnel data changes 
are entered via the CRT, the source of information for changing our data 
base. New employees are entered by keypunching data directly from the 
employee application, supplemented by additional data that is collected 
at the time the employee accepts a position. Both these sources of informa- 
tion are used to update our data base producing a basic master file to be 
used for satisfying many of the requirements we've identified, particularly 
personnel action notices and many other periodic reports. 

We have this system operational on an IBM 370/145. The master file 
itself takes about two 2319 disk packs. We have some six CRT's operational 
within our central office for personnel administration -- three of them in 
our Personnel Office, one in our Payroll area, one in our Insurance Office 
and one in our computer center. 

The following paragraphs simulate how we use these Cathode Ray Tubes 
to interact with our personnel data base by going through the procedure we 
use to make the inquiries into the data base. 

The first display that becomes available when the CRT is available for 
use (which is about six hours during the day) is a display that says that 
the system is available and here's how you use it. Not everybody can use 
it. We have developed a security system where each of the authorized users 
has a security code. Only that security oode is eligible to enter the data 
or to retrieve data. If the user doesn't enter the correct code then they 
will get a message that tells them that they cannot use the system without 
authorization. If they enter the correct code they'll get a message that 
-ays it's correct and here's what they do next. It's designed so that 
i *ople who are using the system don't have to know too much about how to 
use it. They do have to know the security code and they do have to know 
the basic concept of how to press the enter key and the data retrieval 
key. It's designed for the people who are using it, and it has proved 
to be fairly successful. 

The next display would say that you have entered the security code and 
now you have to define what type of information you want. The information 
in the data base is divided into some six major programs. We use a software 
package called FASTER to support the telecommunications activity. (We are 
now converting to CICS.) Knowing the particular employee that the person 
wants to retrieve and knowing the social security number of the employee, 
then the personnel clerk would enter at the bottom of that display the 
program number, PM01 for example, and the social security number of the 
person on whom they want to get data. If they've entered it properly and 
if the computer does find such a person in the file then it will retrieve 
the data for that employee. 
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Each display gives the code for the type of employee and the position 
classification. The first display provides the responsibility location 
(that is the location to which the employee reports), a position control 
number, the location of the employee, his position title and his geographical 
area code. The bottom of the display says that you've retrieved information 
from PM01 and that there are four pages of information in that particular 
series of displays. If the personnel analyst who is retrieving this data 
doesn't know which display provides that data they want, they refer to 
their user manual . 

Assume, in this particular instance, that the personnel analyst 
decided she wanted page 2. On the screen she would enter p/2 which is 
telling the computer "I want to go to page 2." Page 2 includes address, 
telephone number, work location and other personnel information. Again, 
if the personnel analyst wants to go to the next page she would enter page 3 
and would get page 3, She might enter instead p/n which says give me the 
next page. 

Now suppose the personnel analyst got page 4 and then decided she 
wanted to go back to an earlier page. She simply keys in p/p which is 
previous/page. This can be done only within a given progran. For example, 
PM01 contains certain types of data. Ihey can page back and forth like 
leafing through a book for any of the pages within this display series. 
At the top of the display is an indication that there is one record. 
That means there is only one job for that employee. If the employee 
taught adult education at night, he might have two records on the file. 
The file would have different data pertaining to the particular job. 

The display also says that the person is an active employee and it 
shows the particular job classification and employee name on every display. 
If the personnel analyst entered a wrong inquiry code, something like PM10, 
for example, the computer will say that there is no such thing and you've 
got to re-enter with the correct code. 

The next display series, PM02, pertains to salary information. This 
display shows budget code and the number of work units. If the budget 
code had been recently changed it would show the new code also and show 
the date that change would become effective. Other pages show work schedule, 
biweekly gross, and gross income year-to-date. It also shows anniversary 
date and Board Report code, which tells whether the person has been employed 
and approved by the Board of Education. 

Moving on to another series of data, PM03, there are seven pages in that 
display showing leave data. We have a tremendous number of categories of 
leave, more than I could ever comprehend, and we've been asked as one of our 
requirements to maintain this type of data in our data base. The display 
series would show the amount of leave used and the balances for each of the 
various categories, such as sick leave. At this point all these leaves are 
negotiated with our employee groups. We were successful this year (1973) 
for the first time in having our leave categories for professional employees 
tie in directly with those for supporting services employees. We now have 
a unified leave program in our school district which is a major milestone 
as far as we're concerned. 
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PM04 is another series of personnel data, dealing with termination, 
retirement data, and the salaries that are used to determine retirement 
benefits. It also dispUys certification data. This data is particularly 
useful for teachers. It shows the number of years creditable experience, 
and committee assignments for the employee. 

The personnel analyst may by mistake ask for data that he is not 
eligible to look at despite the fact that he had a security code. The 
computer would say that you're not authorized to retrieve that particular 
data. You can only use that data that is assigned to your particular 
department. Then it would refer them back to the user manual to find out 
what they did wrong and what data they are eligible to use. 

If the analyst should enter the wrong social security code, thp 
computer would say that it can't find anybody with that particular social 
security number. If the analyst didn't know the social security number 
but does know the employee name, he can use the computer to help him find 
it. He would enter a request to find the social security number — what 
we call a phonetic key search. 

Assume that they weren't even sure of the employee's first name 
but they know his last name is Smith. Unfortunately we have all kinds of 
Smith's in our school district. The computer would look for Smith and 
start gathering data to display on the CRT for the first Smith we could 
find. Here's what would happen. We would start with the Allen Smith's, 
go through the Barbara's. The display would indicate we had 11 pages 
of Smith's so far. The personnel analyst would leaf through all these 
pages and find there wasn't any Smith that looked something like Robin 
Smith. At page 11, it would say, if you want to look further there are 
more Smith's but we couldn't store them in our buffer area. Put Smith 
in again and let's start gathering the data for display on the 51st 
Smith that you found. Doing that, they would get a series of displays 
and still wouldn't find the record. By going through the process again, 
they would find Robin Smith along with the Robert's and the Ronald's. 
Using the social security number displayed, they could then go in and get 
the particular data record desired. 

There is also the capability to not know how to spell Smith. They 
could spell it Smythe and the computer would collapse that using a phonetic 
key collapse procedure, turning it into a number. The computer would find 
those names that are close to the spelling of Smith. This is particularly 
useful when you get a more difficult name — spell it the way you think 
it is and the computer will help you zero in on what the exact name might 
be. If you know the first name also that's all the better; if you don't 
but you only know the first initial, you put that in. You put in as much 
as you know. The computer will eventually, through iterative cycles, zero 
in on the particular record that you want. 

Earlier it was noted that an employee who has two jobs will be in 
the data base twice — one record for each job. If the social security 
number for a person with two jobs was entered, a message showing her two 
jobs would be shown. The personnel analyst would select the particular 
job that he wanted, entering the data that would allow them to get the 
particular information he desired. 



H3PM is what is keyed in to get off the system. Whenever a personnel 
analyst is finished using the computer she is instructed to key this in. 
It takes away her eligibility to use the system. If she should want to 
use the system again she would then have to enter her security code all 
over again. 

We have a mode of updating in which each data element is identified 
individually or uniquely from all other data elements. Any combination 
of data elements can be entered and accepted by the system. They are 
collected and edited by the system at night as if they were a transaction- 
oriented batch input. The computer generated Personnel Action Notice saves 
a great deal of time for our personnel analysts because they need only enter 
new data to generate a notice. The system collects the old data from the 
personnel data" base and prints out ? form which is sent on to the employee 
and the employee's supervisor, and the Payroll office. There are some 20 
different types of changes that take place such as a transfer and change 
transaction. 

We have 15-20 different types of reports generated from the personnel 
data base. One of the more important ones is our Board Report because 
this is one for which" automation saves a great deal of time for our personnel 
analysts. We have a practice in our school district, which may or may not 
be common in other school districts. Our Board of Education has to approve 
employment actions by Personnel. To do this, Personnel submits a list of 
employments on a monthly basis. We now use the computer to generate all 
these lists by collecting the transactions that have taken place during the 
past month, producing our Board Report, and sending it in computer form to 
our Board* of Education. It shows the summaries of the number of appoint- 
ments for each of the categories of employees, for information to the 
Board, and the details of all the employees that are to be appointed. This 
computer generated output is the official source of information to the 
Board for the appointment actions. It shows other statistics on those 
that are reinstated from leave, other appointments and transfers, etc. 
It shows a summary of our terminations, and the reasons for termination. 
This has been a very useful report. It took a while, admittedly, to get it 
straightened out and select the transactions in the way the Board of Educa- 
tion wanted them. When the Board first got it, they wanted it changed, 
and after they got the change they wanted it changed again. But we finally 
got those things worked out. 

To summarize bur Personnel Master File application, we've found that 
it's fairly successful. It has its weaknesses much as any system would 
but basically it has been very well received. It was a completely new 
thing for our personnel analysts. At this point it's totally ingrained into 
their normal procedures. We're in a way very happy when they complain that 
they aren't getting enough CRT time because that means that they're using 
the system. 

Position Control Application 

The next area that I'll cover in some depth is our position control 
application, which became operational this past fall (1972) after about 
9-12 months effort. This has also proved to be a very successful application. 
I'll cover with you why we developed it, how we got there, the objectives, 
and user needs of that particular application, i'll give you some definitions 
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that we had to pin down in order to implement the application, the inter- 
face it has with other areas we're working in, procedures and responsibilities, 
types of reports that come out of the system, and the benefits which have 
developed from it. I'll mention the transferability of the application 
and what type of plans we have for the future, 

We got into the position control application because the Superintendent 
couldn't get the data he needed about employees and positions. So he made 
a decision in September of 1971 that we had to have a position control 
application. We developed the plan, conducted a systems study in a tradi- 
tional way through a 3-month period (September - December, 1971). By 
January 1972 we had completed a general design, proceeded into a detail 
design through April 1972, programed it and tested it through July 1972 
and converted and validated from July to November 1972. The July to November 
period was about three times as long as we planned for conversion and 
validation. 

One of our first objectives was to define what a position was. This 
seems pretty simple. We had state requirements that said give us position 
information in a certain way. Yet we didn't have a clear definition that 
everyone agreed on, so we had to define some terms and promote them so that 
we were all using the words in the same way. 

We had to account for allocated positions and positions that were not 
allocated -- what we call reserve positions. They are positions held back 
until the schools are open — until we know precisely what pupil enrollment 
is at all the schools. We needed to freeze positions to prevent hiring 
into them for many reasons, such as to free up money because we've overspent, 
or just because the manager may want to use those monies for a different 
type of employee action. We needed to account for positions in supported 
projects, or externally funded projects, which are always handled in 
a slightly different way than the normal procedures in the school district. 
We needed to overlap positions so that when a teacher was terminating we 
could bring in a new teacher with a three or four day overlap and still 
be able to account for the fact that we had, for those three or four days, 
an overhire situation. We needed to be able to create special positions 
to handle needs that were not identified in the budget and account for 
these special actions so they weren't occurring under-the-table. 

The most important requirement was to make sure that the positions 
Personnel was hiring against balanced out to the budget, i.e., the number 
of positions that were authorized in the budget. We had very interesting 
rSsuks in trying to meet this requirement. We had to control our positions 
at multiple levels, that is, account for positions and employees not only 
at the central office level but what we call the area level and at the 
school level* 

We needed to report the numbers and types of positions, as well as 
the filled/vacancy status of the positions. We needed to identify the 
historical status of positions, the current status and even the projected 
status. If the teacher were projected to terminate three months from now, 
we had to keep that information on our data base to develop a report that 
says you're going to get a vacancy three months hence. We needed to 
identify discrepancies between the assignment of an employee and the position 
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authorized something that in our school district had taken place often 
over the years because we have not had an automated position control system. 
We needed to flag problems — problems such as vacancies that have been 
vacated for too long a period for which we can't find an employee, like 
90-day vacancies, or situations where an employee might be charged to the 
wrong account, although it's very difficult in this system to have that 
happen. 

Our first definition of a position is very general. We said, it's 
a "unit of work that has been authorized to meet the needs of MCPS." 
We defined five types of positions permanent, conditional, special, 
anticipated and temporary, and used these as a way of classifying differ- 
ent types of authorizations for people. A permanent position is just 
that -- it's authorized in the budget and it is permanent and continual. 

A conditional position is probably going to continue but it is normally 
funded from external sources and it's continuance is indefinite. A special 
position is a position that is authorized to meet special needs that arise 
during the school year. An anticipated position is a position that's projected 
to be authorized in the months to come. A temporary position is a position 
that's authorized for six months or less, and is normally not authorized in 
the budget. 

We've defined the interfaces for the position control application. First 
of all, the number of positions authorized is provided from our budget 
system. It feeds the approved number of positions over to our position con- 
trol data bank. By the same token at the end of the year the approved number 
of positions that exist at the end of the year are fed back to the budget 
application for the new budget development process. Once position control 
data is in that data bank, the number of positions and their status inter- 
face with the accounting application and with the personnel data bank, 
particularly for employee transfers. The personnel data bank interfaces 
with the accounting data bank particularly in the encumbrance area — the 
projected charging of employee salaries against accounts* Then the 
accounting data interacts with the budget data by showing the number of 
expenditures that have been spent in the previous year. Secondly the 
budget application at the beginning of the year gives the approved number 
of dollars to our accounting data bank so that we're starting out the new 
year with the official approved dollars. 

We had a lot of people looking at the computer in awe when we first 
started this out because some of our users had never worked with a computer 
at all. Their first reaction was, "I don't want anything to do with it, 
I'm very happy the way things are." So we had some obstacles to overcome. 
Everyone was very cooperative, and we got along just fine in developing 
the system. 

The program account managers in particular were supportive of the system 
because they were going to get some new capabilities. The account managers 
are responsible for verifying position control reports. In our school 
district we've tried to design things* in a way where the account manager, 
sometimes called a program manager, is the person responsible for managing 
the money. That doesn't mean that he gets a lump sum and can spend it 
any way he sees fit. The budget spells out what money is authorized for 
what purposes. The account manager is responsible for complying with the 
budget and therefore is responsible for the positions. So we place 
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responsibility for verifying position data on the account or program 
manager. 

We also place the responsibility for initiating transactions to change 
position authorizations on that account manager — to add or modify or 
delete or even freeze positions. He uses what we call a PAR — a Position 
Action Request ~ to initiate an action. It is a very simple, 4-ply NCR 
form, that identifies the position by control number and gives certain data 
such as account code, hours authorized, and the period of authorization. 
This gets forwarded by the program account manager to our personnel office, 
who verify that the form has been filled out correctly. 

The form then is sent to our computer center and keypunched on a 
daily basis. The data bank on employee positions fs updated to show 
the accurate type and numbers of positions. Reports are generated back 
to Personnel and the account manager. By the same token the program 
account manager, and Personnel, can request special reports from the 
data bank on an as needed basis in addition to the periodic reports. 
It's a very low volume, non-volatile procedure because there aren't 
many position changes that take place during the year. 

We have five major reports that are generated from the system, 
but that's somewhat deceiving because the reports come from generalized 
report generators. Many combinations of information can be provided by 
requesting these five reports. These are the five types: 

- Position Action Lists, which show the number of position actions 
that were processed during that day to update the data base. It's 
normally called the Transaction List; 

- A Postion Status Report, which shows the positions for a particular 
program and the status of those positions, whether they're filled 
or vacant and with whom; 

- A Vacancy Report that just selects those positions that are vacant 
and says "You, Mr. Program Manager, have these positions vacant 
for this period of time, and, this is the type of position and 
the account to which it is charged. 1 '; 

- A Discrepancy Report, which shows mismatches between an employee's 
assignment and the authorized position; and finally, 

- An Employee Status by Account, which summarizes all this data 
according to our account code structure. Ultimately we will be 
able to show for each account not only the numbers and types of 
positions that are filled or vacant, but the financial status of 
those positions and the impact of vacancies on those finances. 

A lot of the people using our position control system thought at first 
that it was going to produce a great deal of paper that would be of no 
use to them. It proved out that the computer came through in the end and 
became the knight in shining armor. I'm particularly pleased by one lady 
who started out with the system by saying "I don't want anything to do with 
computers." She had her way of doing things. 

Two weeks ago we had a presentation in the school district about the 
position control application. It made my day when she came up to me and 
said, "You know, I don't even update my manual files any more because 
these reports are so useful to me." I considered that the ultimate 
achievement in implementing a computer application. 
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There are a number of benefits that we feel came out of the position 
control application. First of all, we now have the same data being used by 
account managers and Personnel . Both of them get the same reports about 
positions and the status of those positions, and they can talk to one 
another, That's what we set out to do. They use the same type of employee 
classification codes so when they talk about employees in various classifica 
tion groups, they're talking about the same classification of employees. 
We had to go through a major change in our classification structure to 
get this to happen. We now have our budget, our account managers, and our 
Personnel people all using the same job classification structure. It sounds 
like a simple thing but it has taken a long time to get everyone to agree 
to use it. 

We are now able to track the status of positions. We can identify any 
position in the school district, whether it's filled or vacant, and for 
what periods. For the first time we can tell the Superintendent precisely 
how many positions he has vacant at any point in time. We can show the 
net status and we can do this in a number of ways. We can flag exceptions 
and we can identify long-term vacancies. These are the types of things we 
set out to get out of the system and it has worked out very well. 

We're working right now to enhance the system — tie it more directly 
to some of the other applications to produce some additional reporting 
capabilities revolving around the existing reports. We're making some 
procedural improvements to make it simpler to enter the data. We're 
improving our basis for controlling positions and tying them back to the 
budget. We have not yet incorporated temporary positions into the data base 
but we hope to do that in the future. 

There are a number of aspects of the system that we feel are transfer- 
able to those who have an interest. First of all, Y the design concept is 
very modular. The position part of it can be lifted separately from the 
personnel part of it, and tied into someone else's personnel data bank. We 
did that on purpose because it was partially funded by a state grant. 
Thus, one of our requirements was to design the system in a way such that 
it was transferable to other school districts in the state. The definitions 
have been found to be very useful. We're trying to influence our state 
administrators to use our definitions -- to standardize their requests for 
information from the school districts. 

This is a totally documented system -- it was a pilot project for our 
standards as well. We developed this system using our standards, so we 
have complete design and program documentation, and complete reference 
manuals . 

Overall, our Personnel Subsystem has proved to be an important support- 
ing system to Personnel administration in our school district. 
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